Notebook having secondary processor coupled by a multiplexer to a content source or disk drive

ABSTRACT

In some embodiments, a notebook including a content source (e.g., a DVD or other display data source), mass storage device (e.g., hard disk drive), auxiliary display subsystem (including an auxiliary processor), PC chipset, a multiplexer between the content source, auxiliary processor, and PC chipset, and another multiplexer between the mass storage device, auxiliary processor and PC chipset, and methods implemented thereby. The auxiliary display subsystem can be operable (without communicating with the notebook&#39;s CPU) when the notebook is in a low-power state.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent application Ser. No. 11/398,167, entitled “Method and System for Displaying Data from Auxiliary Display Subsystem of a Notebook on a Main Display of the Notebook” by Arman Toorians, filed on Apr. 5, 2006.

FIELD OF THE INVENTION

The invention pertains to computers and computing systems (e.g., notebook computers). In typical embodiments, the invention pertains to computers and computing systems that include a content source (e.g., a DVD or other display data source), hard disk drive (HDD), auxiliary display subsystem (including an auxiliary processor), PC chipset, a multiplexer between the content source, auxiliary processor, and PC chipset, and another multiplexer between the HDD, auxiliary processor and PC chipset. Typically the auxiliary processor is operable (e.g., without communicating with the notebook's CPU) when the notebook is in a low-power state.

BACKGROUND OF THE INVENTION

The expression “notebook” herein denotes a notebook computer, tablet PC, PDA (personal digital assistant), smart cellular phone (e.g., one capable of playing and displaying multimedia content), or other portable computer or computing system having a central processing unit (“CPU”).

The expression “auxiliary display subsystem” herein denotes a subsystem of a notebook that is configured to receive data (and typically cache the received data) from at least one other element of the notebook and to perform (while the notebook is in a standby state or other low-power state) at least one function that at least one other element of the notebook (external to the auxiliary display subsystem) could perform if the notebook were in a fully-powered normal operating mode. Examples of such functions include displaying cached video, still picture, or other image data (received from an element of the notebook external to the auxiliary display subsystem) or a processed version of such cached data on an auxiliary display, or causing such cached data or a processed version thereof to be displayed on all or part of the screen of the notebook's main display; playing back cached audio data (received from an element of the notebook external to the auxiliary display subsystem) or a processed version of such cached data; displaying system information (e.g., information regarding charge level of a battery of the notebook, or information regarding the notebook's state) on an auxiliary display or causing such system information to be displayed on all or part of the screen of the notebook's main display; and answering incoming telephone calls.

The expression “auxiliary display” herein denotes a display of the auxiliary display subsystem which is distinct from the main display of the notebook in which the auxiliary display subsystem is included. Some embodiments of an auxiliary display subsystem do not include an auxiliary display, and instead are coupled and configured to cause the display of data on all or part of the screen of the main display of the notebook including the auxiliary display subsystem (e.g., while the notebook is in a standby state or other low-power state).

The phrase “auxiliary display data” herein denotes raw auxiliary display data generated by an auxiliary display subsystem, or a scaled or otherwise processed version of such raw auxiliary display data.

The expression “auxiliary processor” of a notebook assumes that the notebook includes an auxiliary display subsystem, and herein denotes a programmable processor of the auxiliary display subsystem (a processor that is programmable with software and/or firmware). An auxiliary processor of a notebook is different and distinct from the notebook's CPU, and a notebook's CPU would not be an element of an auxiliary display subsystem of the notebook.

The expression “secondary processor” of a notebook (having a central processing unit) shall be used herein to denote any processor of the notebook other than the notebook's CPU. Examples of secondary processors of conventional notebook computers are embedded controllers (e.g., embedded controllers that perform keyboard controller functions as well as other functions). An auxiliary processor of a notebook is a secondary processor of the notebook.

The acronym “SMB” herein denotes the conventional, two-wire bus known as the “System Management Bus.” The most recent version of the SMB is described in the System Management Bus (SMB) Specification, Version 2.0, published on Aug. 3, 2000, and available at http://www.smbus.org/specs.

The expression “two-wire” bus or link (as in an “SMB, I2C bus, or other two-wire serial bus”) is used herein as a synonym for “two-conductor” bus or link (i.e., a bus or link having two conductors).

The expression that a notebook is in a “low-power state” herein denotes that the notebook is operating in a state in which it consumes less power than if it were in a fully-powered, normal operating mode. Examples of low-power states are hibernation and standby states. Typically, a notebook has been booted up (and its central processing unit runs operating system software) when operating in a fully-powered normal operating state, but a notebook must perform a booting operation in order to undergo a transition from a low-power state to a fully-powered normal operating state.

It has been proposed that a notebook include an auxiliary display subsystem for caching data received from other elements of the notebook and displaying the cached data on an auxiliary display.

For example, US Patent Application 2004/0225901 (published on Nov. 11, 2004) discloses an auxiliary display system for use with a main computer (a personal computer or other computing device). The auxiliary display subsystem includes an auxiliary display, a memory, an auxiliary processor, and input devices, is operable while the main computer is in a standby state (e.g., to record voicemail, receive an incoming phone call, or play music), and is said to be capable of waking up the main computer while the main computer is in a standby state. The auxiliary display system can execute applications alone (without the main computer) or “in concert” with the main computer's “main processor.” In some implementations, the main computer has a main monitor, and the auxiliary display system is apparently configured to direct “display messages” to the auxiliary display or to forward them for display on the main monitor.

US Patent Application 2004/0222978 (published on Nov. 11, 2004) discloses a control and communications panel for use with a main computer. The control and communications panel can include an auxiliary display, an auxiliary processor, and controls, and can be operable (e.g., to perform telephone or other communication functions) while elements of the main computer are powered down.

US Patent Application 2004/0224638 (published Nov. 11, 2004) discloses a notebook with a built-in docking station for receiving a detachable media player having an auxiliary display and at least one data port (e.g., a USB port) for receiving image, audio, or other data from the notebook or sending data to the notebook. US Application 2004/0224638 suggests generally that communication between the media player and notebook could be one way or two way, and could implement a master/slave, server/client, peer to peer, or other protocol.

US Patent Application 2005/0076088 (published on Apr. 7, 2005) teaches a notebook (or other computer system) having a main display and a detachable module (having a processor, memory, auxiliary display, and input devices such as a fingerprint reader) mounted on the back of the notebook's main display. The detachable module can communicate with the notebook's main processor via a processor bus or communications link (e.g., to wake up the main processor). The detachable module can also perform functions such as displaying email, accessing contact and calendar information, and playing music files (apparently by accessing data previously cached, so as to be accessible by the detachable module, at a time when the notebook was fully powered up and booted up) when the notebook is in a “quiescent low power mode” without the need to boot up the notebook and load its operating system.

SUMMARY OF THE INVENTION

In a class of embodiments, the invention is notebook including an auxiliary display subsystem, a CPU, a keyboard, and a keyboard controller. The auxiliary display subsystem includes at least one auxiliary processor. The auxiliary display subsystem can include an auxiliary display, but typically does not include an auxiliary display. The auxiliary processor is coupled to the keyboard controller by a serial bus (e.g., an SMB, I2C bus, or other two-wire serial bus). In some embodiments, the auxiliary display subsystem (or an auxiliary processor thereof), the keyboard, and the keyboard controller are operable (without communicating with the CPU) when the notebook is in a low-power state. In some embodiments in this class, the notebook includes a display (to be referred to herein sometimes as a “main” display), a PC chipset (including the CPU), a graphics chipset coupled to the PC chipset, and a multiplexer between the auxiliary processor and the graphics chipset. The notebook is configured to be operable (e.g., while in a standby state or other low-power state) to display auxiliary display data (passed by the multiplexer to the main display) on a portion of the main display's screen, or (e.g., while in a fully powered state) to display data from the graphics chipset (passed by the multiplexer to the main display) on the main display's screen. Optionally, the notebook is configured to display auxiliary display data on the entire screen of the main display and/or to display auxiliary display data and display data from the graphics chipset on different parts of the main display's screen.

In some embodiments in the class described in the previous paragraph, the notebook also includes a content source (e.g., a DVD drive or other display data or audio data source) and a mass storage device (e.g., a hard disk drive or “HDD,” or flash memory unit), a second multiplexer between the content source, the auxiliary processor, and the PC chipset, and a third multiplexer between the mass storage device, the auxiliary processor and the PC chipset. By controlling the second multiplexer, video data, image data, other display data (or other content) can be routed from the content source to either the auxiliary processor or the PC chipset. By controlling the third multiplexer, display data (or other content) can be routed from the mass storage device to either the auxiliary processor or the PC chipset. Optionally, either the second multiplexer or the third multiplexer is omitted.

In a class of embodiments, the invention is a notebook including a CPU, at least one secondary processor (e.g., an auxiliary processor of an auxiliary display subsystem of the notebook), a keyboard, and a keyboard controller. A secondary processor of the notebook is coupled to the keyboard controller by a serial bus (preferably an SMB, I2C bus, or other two-wire serial bus). These embodiments allow touch pad devices, touch point devices, and finger print sensors (or other biometric sensors) to be integrated with the keyboard controller.

Other aspects of the invention are methods implemented by any embodiment of the inventive notebook.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an embodiment of the inventive notebook which includes an auxiliary display subsystem (personal media display system or “PMD” 3) coupled to an embedded controller (11) of the notebook. PMD 3 is also coupled by a USB (universal serial bus) to PC chipset 9 of the notebook.

FIG. 2 is a block diagram of a typical implementation of PMD 3 of FIG. 1.

FIG. 3 is a block diagram of an embodiment of the inventive notebook which includes an auxiliary display subsystem (PMD 103), a main graphics subsystem (graphics chipset 15), and a timing controller (108) configured to assert display data from microprocessor 5 of PMD 103 (or a scaled or otherwise processed version of such data) and/or from chipset 15 to main display 107 with timing for display on all or a selected portion of main display 107's screen.

FIG. 4 is a block diagram of a subsystem of the notebook FIG. 3, including elements of an implementation of timing controller 108.

FIG. 5 is a simplified side cross-sectional view of a main display (LCD panel 207) that can be included in an embodiment of the inventive notebook, showing elements of the FIG. 4 subsystem coupled thereto.

FIG. 6 is a front view of the screen (210) of main display 207 of FIG. 5, showing some pixels 211 thereof.

FIG. 7 is a block diagram of elements of another notebook computer that embodies the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In some embodiments of the invention, a conventional System Management Bus (SMB) is used as the underlying transport layer for communications between an auxiliary display subsystem (e.g., an auxiliary processor of an auxiliary display subsystem) and a secondary processor of a notebook, or between a secondary processor of a notebook and a keyboard controller or other element of the notebook. The bus protocols implemented by some embodiments of the invention for communication over an SMB between an auxiliary display subsystem (or other element of a notebook) and a secondary processor are compliant with the above-cited System Management Bus (SMB) Specification, Version 2.0. Notation used herein for SMB protocol description is consistent with that employed in the cited System Management Bus (SMB) Specification, Version 2.0.

FIG. 1 is a block diagram of notebook computer (“notebook”) 1 which includes conventional PC chipset 9 (including a CPU which runs notebook 1's operating system software when notebook 1 has been booted up into its fully-powered normal operating mode), graphics chipset 15, main display 17, embedded controller (EC/KBC 11), and keyboard 13, connected as shown. EC/KBC 11 is of a conventional type which functions as a keyboard controller. EC/KBC 11 is coupled to keyboard 13 (e.g., by a conventional 26-pin cable) and typically also to other elements (not shown in FIG. 1) of notebook 1.

Still with reference to FIG. 1, EC/KBC 11 is coupled to chipset 9 by a conventional low pin count (“LPC”) bus. In alternative implementations, EC/KBC 11 is coupled to chipset 9 by other means (e.g., by a conventional ISA bus or other bus).

Notebook 1 also includes an auxiliary display subsystem (personal media display system 3, to be referred to as “PMD” 3) which includes microprocessor 5 (“auxiliary processor” 5), auxiliary display 7 (coupled to and driven by microprocessor 5), and typically also other elements (to be described below). Microprocessor 5 is coupled by an SMB to EC/KBC 11 for communication with EC/KBC 11, and EC/KBC 11 is configured to operate as a conventional SMB host. Microprocessor 5 is coupled by a conventional USB (universal serial bus) to PC chipset 9 for communication with PC chipset 9. Typically, microprocessor 5 communicates with EC/KBC 11 over the SMB when chipset 9 is in a low-power state (e.g., a standby or hibernation state) or when chipset 9 is fully awake (and in a state in which it consumes full power), and microprocessor 5 communicates with chipset 9 over the USB when chipset 9 is fully awake (and in a state in which it consumes full power).

Notebook 1 typically includes elements (not shown in FIG. 1) in addition to those shown in FIG. 1. For example, it can include a smart battery (coupled to EC/KBC 11 by an SMB) and a smart battery charger (also coupled to EC/KBC 11 by an SMB).

PMD 3 typically also includes other elements (not shown in FIG. 1). For example, PMD 3 typically includes input devices (e.g., control buttons and a biometric sensor) and a memory. PMD 3 is typically configured to cache data received from other elements of notebook 1 as a result of communication over the USB between microprocessor 5 and PC chipset 9. PMD 3 is typically configured to display such cached data (in the case that the cached data are video or other image data) on auxiliary display 7 and to play back the cached data (in the case that the cached data are audio data) on loudspeakers (not shown) of notebook 1. PMD 3 is typically also configured to display (on auxiliary display 7) system status data received by microprocessor 5 from EC 11 over the SMB.

Examples of system status data that can be received by PMD 3 (e.g., for display on auxiliary display 7) from the non-PMD portion of notebook 1 (e.g., from EC 11 as described below) include indications that notebook 1 is on, off, shutting down, or powering up, indications that notebook 1 is in a standby, suspended, or hibernation state, indications that a battery of notebook 1 is charging or discharging, indications of the charge level of a battery of notebook 1, low battery alarms, indications that communication with the non-PMD portion of notebook 1 is in progress, notifications that the non-PMD portion of notebook 1 has received new email, and current time and date updates.

PMD 3 can also be configured to perform, while PC chipset 9 is in a standby or other low-power state, other functions (e.g., answering incoming telephone calls) that other elements of notebook 1 could perform if notebook 1 were in a fully-powered, normal operating state. When PC chipset 9 is in a low-power state, other major power-consuming elements of notebook 1 (e.g., main display 17) are typically off or in a standby or other low-power state so that notebook 1 as a whole is in a low-power state. Preferably, microprocessor 5 and other elements of PMD 3 are implemented to consume less power (preferably, much less power) than consumed by the elements of notebook 1 other than PMD 3 in a fully-powered, normal operating state. Thus, a user can employ PMD 3 to conserve power while performing useful functions of notebook 1 (while notebook 1 is in a low-power state), without the need to cause notebook 1's CPU (implemented by PC chipset 9) to boot up (which would typically consume significant time).

Functions that can be performed by various embodiments of PMD 3 include cached music file playing (with optional equalization, sample rate conversion, or other audio post processing), display of cached picture slide shows (e.g., on auxiliary display 7), display of world clock, time, and date information, stop watch functionality, display of contact lists, email, reminder memos, timed memos, task lists, battery and other information regarding notebook 1 and users thereof (e.g., user name and information, system information, manufacturer, serial number and model number, OEM support, technical contact information, and logos), password/screen lock support functions, system functions (e.g., placing notebook in an on, off, hibernation, standby, or suspend state), and lid-closed notebook system and application control functions.

FIG. 2 is a block diagram of a typical implementation of PMD 3 of FIG. 1. In the FIG. 2 implementation, microprocessor 5 is a dual core, ARM-based microprocessor implemented to consume low power (e.g., to operate for 50 hours on power drawn from an AA battery), auxiliary display 7 includes touch-screen controller, a resistive touch panel screen, display lighting, and control buttons and a thumb wheel, connected as shown. Typically, when notebook 1 has the size and physical form of a conventional notebook computer (and thus includes a keyboard section and a cover attached by hinges to the keyboard section, with the main display installed to be visible from the cover's front surface), PMD 3 is installed in the notebook computer's cover with the touch panel screen, control buttons, and thumb wheel of auxiliary display 7 accessible from the cover's back surface (so as to be accessible when the cover's front surface is folded against the keyboard section to protect the main display).

In the FIG. 2 implementation, PMD 3 includes communication interface subsystem 33 (coupled to microprocessor 5), which can include high speed serial interface 34, Bluetooth module 36, USB interface 38 (configured to be coupled by USB conductors to PC chipset 9), GPIO interface 40, and EC interface 41 (configured to be coupled by SMB conductors to EC/KBC 11), and other interface circuitry (e.g., RF, 802.11, Ethernet, and/or IR interface circuitry). In the FIG. 2 implementation, microprocessor 5 includes an internal boot block ROM (not separately shown), and PMD 3 includes NOR/NAND flash memory 29 and SRAM/SDRAM 31, security input device 21 (e.g., a key lock), audio DAC 23, and fingerprint sensor 27, all coupled to microprocessor 5. Audio amplifier 25 is coupled to the output of DAC 23 for amplifying the analog audio that is output from DAC 23, and amplifier 25 can drive speakers which are external to PMD 3 (e.g., headphones plugged into a connector of PMD 3).

Fingerprint sensor 27 is used to authenticate users of PMD 3, using user identity data cached in memory (e.g., memory 29 or 31) of PMD 3. When typically programmed, PMD 3 can be placed in a locked state in which it can be unlocked by an authorized user only after PMD 3 successfully authenticates the user (even while notebook 1 is in a standby state or other low-power state, and without waking up notebook 1) including by comparing user biometric data (e.g., a fingerprint) with cached biometric data.

In the FIG. 2 implementation, PMD 3 also includes analog power management circuitry 35 coupled to microprocessor 5. Circuitry 35 includes at least one voltage regulator (e.g., voltage regulators for regulating each of a 2.9 Volt digital supply voltage, a 2.9 Volt analog supply voltage, a peripheral supply voltage in the range 1.7 to 3.3 Volts, an RTC supply voltage in the range 1 Volt to 2.5 Volts, and a 3.26 Volt USB transceiver voltage), a battery charger, a backup battery, and a DC-to-DC converter for providing a 3.2 or 3.4 V output in response to an input voltage in the range from 1.0 Volt to 3.3 Volts.

PMD 3 is typically configured to cache (e.g., in memory 29 and/or memory 31) data received from other elements of notebook 1 as a result of communication over the USB between microprocessor 5 and PC chipset 9. PMD 3 is typically configured to display such cached data (in the case that the cached data are video or other image data) on auxiliary display 7 and to play back the cached data (in the case that the cached data are audio data) on loudspeakers (not shown) of notebook 1. PMD 3 is typically also configured to display (on auxiliary display 7) system status data received by microprocessor 5 from EC/KBC 11 over the SMB. Microprocessor 5 (and other elements of PMD 3) can also be configured to implement digital rights management (e.g., to decrypt content received from elements of notebook 1 external to PMD 3, and to store, in read-only memory, unique identification data for digital rights management algorithms).

PMD 3 is typically also configured to perform one or more of the following functions:

provide low power, instant access to music and multimedia content cached in memory (e.g., memory 29 and/or memory 31) of PMD 3 and other information (e.g., critical information) cached in memory of PMD 3 (e.g., frequently used information transferred from other elements of notebook 1 and cached in PMD 3 before notebook 1 enters a standby or other low-power state);

allow a user to control notebook 1 with the cover of main display 17 closed (e.g., by waking up notebook 1 and controlling notebook 1 by actuating controls on or associated with auxiliary display 7, while main display 17 is covered and thus protected and unavailable); and

provide other functionality such as generating alarms (e.g., for elapsed time or scheduled events, or low battery alarms indicating that notebook 1's battery is nearly discharged), implementing user authentication (or other security functions) preliminary to booting of notebook 1's CPU, collecting and monitoring system diagnostics data (e.g., data indicating whether notebook 1 is shutting down, powering up, whether notebook 1 is in an on, off, standby, suspended, or hibernation state, whether notebook 1's battery is charging/discharging, and the charge level of notebook 1's battery), and communicating with notebook 1's operating system software regarding system power management policies.

Microprocessor 5 is preferably programmed with firmware for executing appropriate functions and with software for executing functions including the following: boot block (e.g., for initializing microprocessor 5's CPU and PMD 3's flash memory 29 and other memory, authenticating a firmware boot loader in PMD 3's flash memory 29, and loading and executing a firmware boot loader), boot loader support (stored in PMD 3's flash memory 29, for authenticating firmware and device drivers and executing firmware), firmware kernel, file system, graphic tool kit, and drivers (e.g., USB, SMB, I2S, display controller, touch screen, and JTAG debugger support).

Several elements of the FIG. 2 implementation of PMD 3 (e.g., microprocessor 5 and circuitry 23, 25, and 35) can be and preferably are integrated in a single chip.

We next describe communication over an SMB between an auxiliary processor and a secondary processor (e.g., auxiliary processor 5 and secondary processor 11 of FIG. 1) of a class of embodiments of the inventive notebook. Any device on an SMB has a unique 7-bit address. In a conventional notebook architecture, the embedded controller which functions as keyboard controller is conventionally assigned SMB host device address 0001_000 b.

In a class of implementations of FIG. 1, microprocessor 5 (an auxiliary processor) is assigned SMB device address 1000_101 b as a default address for receiving messages over the SMB between microprocessor 5 and EC/KBC 11, and EC/KBC 11 (a secondary processor) is assigned SMB host device address 0001_000 b for receiving messages over the SMB. Preferably, notebook 1 of FIG. 1 is implemented so that if another device (a device other than microprocessor 5) with the address 1000_101 b is connected to the same SMB segment as is microprocessor 5, the default address for microprocessor 5 can be reprogrammed in firmware. In such implementations, typical SMB messages sent from microprocessor 5 (an SMB device acting as bus master) to EC/KBC 11 (an SMB host controller acting as bus slave) include data requests and action requests of any of the types described below.

In some such implementations, microprocessor 5 (an SMB device acting as bus master) sends messages to EC/KBC 11 (an SMB host controller acting as bus slave) in accordance with the SMB host notify protocol described in the above-cited SMB specification. In accordance with this protocol, the SMB device master can send to the SMB host controller (functioning as an SMB slave) 16-bit messages (each preceded by two 8-bit words that indicate the target and sending device addresses, with transmission of each 8-bit word followed by an “acknowledge” bit) in the following format:

1 7 1 1 7 1 1 8 1 8 1 1 S Target Address Wr A Sending Device A Data Byte Low A Data Byte High A P Address SMB Host 0 0 PMD Address 0 0 Command 0 Sub-Command 0 Address

In the previous paragraph, “S” denotes the conventional SMB “start condition” which the transmitter of the message (the SMB device master) must assert on the SMB to indicate the start of transmission of a message comprising a number of 8-bit packets separated by “acknowledge” bits, “Wr” denotes a command bit (whose bit value is 0 during transmission in accordance with the host notify protocol), “A” denotes an acknowledge bit (whose value is 0 for an ACK and 1 for a NACK), “P” denotes the conventional SMB “stop condition” which the message transmitter asserts on the SMB to indicate the end of transmission of a message, and the two 8-bit words “Data Byte Low” and “Data Byte High” are the body of the message. The 8-bit sending device address indicates to the message recipient (the SMB host controller slave) the origin of the message.

Depending on the command field value (the above-indicated 8-bit word “Data Byte Low”), all messages from microprocessor 5 to EC/KBC 11 can be divided into two categories: data requests and action requests.

In some embodiments, data requests (asserted from microprocessor 5 to EC/KBC 11) have the format indicated in Tables 1 and 2 below. Table 1 indicates the format of each data request's command field value (the above-indicated 8-bit word “Data Byte Low”), and Table 2 indicates the format of each data request's sub-command field value (the above-indicated 8-bit word “Data Byte High”) and bits 3:0 of the data request's command field.

TABLE 1 Data Request Commands Command Field Bit(s) Description 7:5 Requestor Tag 000b - Invalid Others - Assigned by microprocessor 5 (no context for EC/KBC 11) 4 Message Type 0b - Data Request 3:0 Command Code 0h - EC/KBC Capabilities 1h - System Status 2h - Battery Information Others - Reserved

TABLE 2 Data Request Sub-Commands Command Sub- Field Command Bits 3:0 Field Bit(s) Description 0h 7:0 Reserved (00h) 1h 7:0 Reserved (00h) 2h 7:4 Battery Slot Tag 0h - Battery Slot 0 1h - Battery Slot 1 2h - Battery Slot 2 3h - Battery Slot 3 Others - Reserved 3:0 Battery Information 0h - Battery Slot Status and Capacity Gauge 1h - Battery Voltage 2h - Battery Remaining Time to Empty 3h - Battery Charging/Discharging Rate 4h - Battery Remaining Capacity 5h - Battery Last Full Charge Capacity 6h - Battery Design Capacity 7h–Bh - Reserved Ch - Battery Manufacturer Name Dh - Battery Model Eh - Battery Type Fh - Reserved

In accordance with some embodiments, action requests (asserted from microprocessor 5 to EC/KBC 11) have the format indicated in Tables 3 and 4 below. Table 3 indicates the format of each action request's command field value (the above-indicated 8-bit word “Data Byte Low”), and Table 4 indicates the format of each action request's sub-command field value (the above-indicated 8-bit word “Data Byte High”) and bits 3:0 of the action request's command field.

TABLE 3 Action Request Commands Command Field Bit(s) Description 7:5 Requestor Tag 000b - Invalid Others - Assigned by microprocessor 5 (no context for EC/KBC 11) 4 Message Type 1b - Action Request 3:0 Command Code 0h - EC GPIO Control 1h - System Sleep State control 2h - Generate System Wake Event 3h - Generate System Run Time Event Others - Reserved

TABLE 4 Action Request Sub-Commands Sub- Command Field Command Bits 3:0 Field Bit(s) Description 0h 7:6 Reserved (00b) 5:4 Requested GPIO state 00b - Output Low 01b - Output High 1Xb - Input 3:0 EC GPIO number (mapping of this number to EC/KBC 11's physical GPIO is preferably done by EC firmware) 00h–0Fh - GPIO0–GPIO15 1h 7:0 Requested System Sleep State 00h - Invalid 01h - ACPI S1 state (Standby) 02h - ACPI S2 State 03h - ACPI S3 State (Suspend to RAM) 04h - ACPI S4 State (Suspend to Disk, Hibernation) 05h - ACPI S5 State (System is Off) 06h - User defined state (emulate power/sleep button event) Others - Reserved 2h 7:0 PMD Wake Event ID reported by EC/KBC 11 to PC chipset 9 of notebook 1 00h–FFh - ID0–ID255 3h 7:0 PMD Run Time Event ID reported by EC/KBC 11 to PC chipset 9 of notebook 1 00h–FFh - ID0–ID255

In Tables 3 and 4, “GPIO” denotes “general purpose input/output.” Action requests having the values indicated in Tables 3 and 4 in their command and sub-command fields can be asserted over the SMB to EC/KBC 11 to cause EC/KBC 11 to assert values (indicated by the messages) on specific GPIO pins of EC/KBC 11 (also indicated by the messages) to control other elements of the notebook. The GPIO connections (to the elements of the notebook to be controlled) could be of a type present in a conventional notebook, but they are controlled in some embodiments of the present invention by action requests asserted from PMD 3 over an SMB (or another serial bus, in alternative embodiments) to EC/KBC 11 (or another embedded controller). For example (in one embodiment), microprocessor 5 of PMD 3 could assert action request messages over the SMB of FIG. 1 (or FIG. 3) to EC/KBC 11 to cause EC/KBC 11 to assert control bits (indicated by the messages) on specific GPIO lines (also indicated by the messages) to an audio amplifier of the notebook, where such amplifier (not shown in the Figures) is coupled in a conventional manner to EC/KBC 11 by such GPIO lines.

In variations on the notebook of FIG. 1, action requests of the described type are asserted over an SMB (e.g., from an auxiliary processor other than microprocessor 5) directly to a keyboard controller, with the keyboard controller acting as bus slave, or similar action requests are asserted over another two-wire serial bus (e.g., from an auxiliary processor other than microprocessor 5) to a keyboard controller. In these variations, the keyboard controller can also be coupled by another two-wire serial bus to a secondary processor of the notebook (e.g., an embedded controller) so that either the secondary processor or the auxiliary processor coupled to the keyboard controller can control the keyboard controller over a two-wire serial bus.

We next describe messages sent over the SMB from EC/KBC 11 (an SMB host controller acting as bus master) to microprocessor 5 (an SMB device acting as bus slave), or from another SMB host controller acting as bus master to microprocessor 5 (or another SMB device acting as bus slave). In some embodiments, the SMB write block protocol with the following format is used for all messages sent over the SMB from EC/KBC 11 (acting as bus master) to microprocessor 5. In accordance with this protocol, the SMB host controller master can send to microprocessor 5 (functioning as an SMB slave) N*8-bit messages (where N is an integer), each preceded by three 8-bit words that indicate microprocessor 5's address, a data report command, and a message byte count (indicative of the value of N), with transmission of each 8-bit word followed by an “acknowledge” bit) in the following format:

1 7 1 1 8 1 8 1 8 1 S Slave Address Wr A Command A Byte Count A Data Byte 1 A . . . PMD Address 0 0 Data Report 0 N (2–32) 0 Sub-Command 0 Command 8 1 8 1 8 1 8 1 ¹ Data Byte 2 A Data Byte 3 A . . . Data Byte N A PEC¹ A P Report Status 0 Report Data 0 Report Data 0 0

In the previous paragraph, “S” denotes the conventional SMB “start condition” which the transmitter of the message (the SMB host controller acting as bus master) must assert on the SMB to indicate the start of transmission of a message comprising a number of 8-bit packets separated by “acknowledge” bits, “Wr” denotes a command bit (whose bit value is 0 during transmission in accordance with the write block protocol), “A” denotes an acknowledge bit (whose value is 0 for an ACK and 1 for a NACK), “PEC” is a Packet Error Code, “P” denotes the conventional SMB “stop condition” which the message transmitter asserts on the SMB to indicate the end of transmission of a message, and the N 8-bit words “Data Byte” are the body of the message. The 7-bit slave address is the address of microprocessor 5. The Packet Error Code (PEC) byte is an optional CRC-8 error checking byte, and if included, it is appended after the last Data Byte of the message body and its usage is consistent with the PEC support bit included in an EC Capabilities Report (see Table 8 below).

Messages having the above-described format that are sent over the SMB from EC/KBC 11 (acting as bus master) to microprocessor 5 (acting as bus slave) are Data Report messages (each comprising N bytes that follow three initial address, command, and message byte count bytes), with the first byte of each N-byte message being a sub-command (i.e., the sub-command field of the Data Report Message), and the second byte of each N-byte message being a Report Status byte. A non-zero value of the Report Status byte indicates report failure. If the Report Status byte has a zero value, the report data transferred in the subsequent bytes of the message provide system information according to the command and sub-command fields.

The command byte transmitted following the address byte is sometimes denoted herein as the Command field of the Data Report Message. The content of the Command and Sub-Command fields of Data Report Messages from EC/KBC 11 is summarized in Table 5 and Table 6 below.

TABLE 5 Data Report Commands Command Field Bit(s) Description 7:5 Requestor Tag 000b - No requestor (message initiated by EC/KBC 11 itself) Others - Same as in the PMD data request which triggered the report (used internally by microprocessor 5 to properly route the report) 4 Message Type 0b - Data Report 3:0 Command Code 0h - EC Capabilities 1h - System Status 2h - Battery Information Others - Reserved

TABLE 6 Data Report Sub-Commands Command Sub- Field Command Bits 3:0 Field Bit(s) Description 0h 7:0 Reserved (00h) 1h 7:0 Reserved (00h) 2h 7:4 Battery Slot Tag 0h - Battery Slot 0 1h - Battery Slot 1 2h - Battery Slot 2 3h - Battery Slot 3 Others - Reserved 4:0 Battery Information 0h - Battery Slot Status and Capacity Gauge 1h - Battery Voltage 2h - Battery Remaining Time to Empty 3h - Battery Charging/Discharging Rate 4h - Battery Remaining Capacity 5h - Battery Last Full Charge Capacity 6h - Battery Design Capacity 7h–Bh - Reserved Ch - Battery Manufacturer Name Dh - Battery Model Eh - Battery Type Fh - Reserved

The Command and Sub-Command fields for each Data Report message from EC/KBC 11 are the same as the respective fields in the above-described data requests from microprocessor 5 with one exception: a “no requestor” tag can be specified if a Data Report is initiated by EC/KBC 11 itself (and is not a response to a data request from microprocessor 5).

Table 7 specifies values of the Report Status byte (the above-described second byte) of each N-byte Data Report message, and allowable Byte Count values that correspond to each value of the Report Status byte.

TABLE 7 Data Report Status and Byte Count Report Status Byte Count Description 00h 3–32 Report Successful. Following the Report Status byte, at least one data byte is, and as many as 30 data bytes are, returned according to the command and subcommand fields 01h 2 Report Failed: attempt to access unsupported battery slot, or access to empty slot. A Battery Slot Status report must be returned successfully even for an empty slot. The “battery present flag” should be cleared in this case. 02h 2 Report Failed: unknown data 0FFh 2 Report Failed: any other reason than described above Others 2 Reserved

No data is reported by failed report (no data bytes follow a Report Status byte having a non-zero value). Data fields for all successful Data Reports from EC/KBC 11 are defined below (the requester tag for all report examples below is set to 001 b).

Table 8 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of an “EC Capabilities” Data Report message (indicated in Tables 1 and 5 above).

TABLE 8 EC Capabilities Data Report SMB Protocol Byte Value Note Command Byte 20h Byte Count 08h Data Byte 1 (Sub- 00h Command) Data Byte 2 00h Successful (Report Status) Data Byte 3 Version Number Indicates the specification version with (10h = version which EC/KBC 11 is compliant (the major 1.0) version is specified in the high nibble, the minor version in the low nibble) Data Byte 4 GPIO allocation Number of GPIO pins of EC/KBC 11 that are allocated for PMD control (up to 16) Data Byte 5 Battery System See Table 9 Configuration Data Byte 6 Supported See Table 10 System Sleep States Data Byte 7 Reserved (00h) Data Byte 8 Reserved (00h)

TABLE 9 Battery System Configuration Battery System Configuration Bit(s) Description 7:5 Reserved (000b) 4 PEC Support bit 0b - EC messages to microprocessor 5 do not use a protocol with PEC 1b - EC messages to microprocessor 5 use a protocol with PEC 3:0 Number Battery Slots (maximum number of batteries in the system) 0h - Invalid 1h - One Battery Slot 0 2h - Two Battery Slots 1 and 2 3h - Three Battery Slots 0, 1 and 2 4h - Four Battery Slots 0, 1, 2 and 3 Others - Reserved

TABLE 10 System Sleep States Support System Sleep Sate Support Bit(s) Description 7 Reserved (0b) 6 User defined state (emulate power/sleep button event) 5 ACPI S5 state (System is Off) 4 ACPI S4 state (Suspend to Disk, Hibernation) 3 ACPI S3 state (Suspend to RAM) 2 ACPI S2 state 1 ACPI S1 state (Standby) 0b - Sleep state is not supported 1b - Sleep state is supported 0 Reserved (0b)

Table 11 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “System Status” Data Report message (indicated in Tables 1 and 5 above).

TABLE 11 System Status Report SMB Protocol Byte Value Note Command Byte 21h Byte Count 08h Data Byte 1 00h (Sub-Command) Data Byte 2 00h Successful (Report Status) Data Byte 3 System State Bits 7–0 See Table 12 Data Byte 4 System State Bits 15–8 See Table 12 Data Byte 5 GPIO State Bits 7–0 Each bit 15–0 returns the Data Byte 6 GPIO State Bits 15–8 state of the respective GPIO pin, GPIO15–GPIO0. Non supported GPIOs should be reported as “0.” Data Byte 7 Reserved (00h) Data Byte 8 Reserved (00h)

TABLE 12 System State Flags System State Bit(s) Description 15 Battery in Slot 3 Present 14 Battery in Slot 2 Present 13 Battery in Slot 1 Present 12 Battery in Slot 0 Present 0b - Battery is not present in the respective Slot 1b - Battery is present in the respective Slot 11:6  Reserved (000000b)  5 LID State 0b - LID closed 1b - LID open  4 AC Present 0b - No AC (Battery Power) 1b - AC Present 3:0 System Power State 0h - ACPI S0 state (System is On) 1h - ACPI S1 state (Standby) 2h - ACPI S2 State 3h - ACPI S3 State (Suspend to RAM) 4h - ACPI S4 State (Suspend to Disk, Hibernation) 5h - ACPI S5 State (System is Off) Others - Reserved

Table 13 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Slot Status and Capacity Gauge” type (indicated in Table 6 above).

TABLE 13 Battery Information (Slot Status and Capacity Gauge) Report SMB Protocol Byte Value Note Command Byte 22h Byte Count 04h Data Byte 1 X0h X = 0h for Battery in Slot 0 (Sub-Command) X = 1h for Battery in Slot 1 X = 2h for Battery in Slot 2 X = 3h for Battery in Slot 3 Data Byte 2 00h Successful (Report Status) Data Byte 3 Battery Slot Status See Table 14 Data Byte 4 Battery Capacity Battery's relative Gauge remaining capacity in %

TABLE 14 Battery Slot Status Status Bit(s) Description 7:5 Reserved (000b) 4 Discharging Alarm 0b - No alarm 1b - Alarm is set 3 Charging Alarm 0b - No alarm 1b - Alarm is set 2:1 Charging state 00b - Battery is idle (self-discharging) 01b - Battery is being charged 10b - Battery is being discharged (powering the system) 11b - Reserved 0 Present State 0b - Battery is not present in the respective slot 1b - Battery is present in the respective slot

Table 15 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Voltage” type (indicated in Table 6 above).

TABLE 15 Battery Voltage Report SMB Protocol Byte Description Note Command Byte 22h Byte Count 04h Data Byte 1 X1h X = 0h for Battery in Slot 0 (Sub-Command) X = 1h for Battery in Slot 1 X = 2h for Battery in Slot 2 X = 3h for Battery in Slot 3 Data Byte 2 00h Successful (Report Status) Data Byte 3 Present Voltage Battery's present voltage Bits 7–0 (16-bit unsigned value, Data Byte 4 Present Voltage in [mV]) Bits 15–8

Table 16 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Remaining Time to Empty” type (indicated in Table 6 above).

TABLE 16 Battery Remaining Time to Empty Report SMB Protocol Byte Description Note Command Byte 22h Byte Count 04h Data Byte 1 X2h X = 0h for Battery in Slot 0 (Sub-Command) X = 1h for Battery in Slot 1 X = 2h for Battery in Slot 2 X = 3h for Battery in Slot 3 Data Byte 2 00h Successful (Report Status) Data Byte 3 Time to Empty Bits 7–0 Estimated remaining time Data Byte 4 Time to Empty Bits 15–8 to empty for discharging battery at present rate (in [min]) Report 0FFFFh if battery is not discharging

Table 17 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Charging/Discharging Rate” type (indicated in Table 6 above).

TABLE 17 Battery Charging/Discharging Rate Report SMB Protocol Byte Description Note Command Byte 22h Byte Count 06h Data Byte 1 X3h X = 0h for Battery in Slot 0 (Sub-Command) X = 1h for Battery in Slot 1 X = 2h for Battery in Slot 2 X = 3h for Battery in Slot 3 Data Byte 2 00h Successful (Report Status) Data Byte 3 Rate Bits 7–0 Battery's charging/discharging Data Byte 4 Rate Bits 15–8 rate (24-bit unsigned value in Data Byte 5 Rate Bits 23–16 specified Rate Units; direction is reported in Slot Status). Data Byte 6 Rate Units 00h = [mW] 01h = [mA] 02h = [10 mW]

Table 18 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Remaining Capacity” type (indicated in Table 6 above).

TABLE 18 Battery Remaining Capacity SMB Protocol Byte Description Note Command Byte 22h Byte Count 06h Data Byte 1 X4h X = 0h for Battery in Slot 0 (Sub-Command) X = 1h for Battery in Slot 1 X = 2h for Battery in Slot 2 X = 3h for Battery in Slot 3 Data Byte 2 00h Successful (Report Status) Data Byte 3 Capacity Bits 7–0 Battery's remaining capacity Data Byte 4 Capacity Bits 15–8 (24-bit unsigned value Data Byte 5 Capacity Bits 23–16 in specified Capacity Units) Data Byte 6 Capacity Units 00h = [mWh] 01h = [mAh] 02h = [10 mWh]

Table 19 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Last Full Charge Capacity” type (indicated in Table 6 above).

TABLE 19 Battery Last Full Charge Capacity SMB Protocol Byte Description Note Command Byte 22h Byte Count 06h Data Byte 1 X5h X = 0h for Battery in Slot 0 (Sub-Command) X = 1h for Battery in Slot 1 X = 2h for Battery in Slot 2 X = 3h for Battery in Slot 3 Data Byte 2 00h Successful (Report Status) Data Byte 3 Capacity Bits 7–0 Battery's capacity when fully Data Byte 4 Capacity Bits 15–8 charged last time (24-bit Data Byte 5 Capacity Bits 23–16 unsigned value in specified Capacity Units) Data Byte 6 Capacity Units 00h = [mWh] 01h = [mAh] 02h = [10 mWh]

Table 20 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Design Capacity” type (indicated in Table 6 above).

TABLE 20 Battery Design Capacity SMB Protocol Byte Description Note Command Byte 22h Byte Count 06h Data Byte 1 X6h X = 0h for Battery in Slot 0 (Sub-Command) X = 1h for Battery in Slot 1 X = 2h for Battery in Slot 2 X = 3h for Battery in Slot 3 Data Byte 2 00h Successful (Report Status) Data Byte 3 Capacity Bits 7–0 Battery's design (24-bit Data Byte 4 Capacity Bits 15–8 unsigned value in specified Data Byte 5 Capacity Bits 23–16 Capacity Units) Data Byte 6 Capacity Units 00h = [mWh] 01h = [mAh] 02h = [10 mWh]

Table 21 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Manufacturer” type (indicated in Table 6 above).

TABLE 21 Battery Manufacturer Report SMB Protocol Byte Description Note Command Byte 22h Byte Count N = 03h–20h Data Byte 1 XCh X = 0h for Battery in Slot 0 (Sub-Command) X = 1h for Battery in Slot 1 X = 2h for Battery in Slot 2 X = 3h for Battery in Slot 3 Data Byte 2 (Report Status) 00h Successful Data Byte 3–Data Byte N ASCII string Manufacturer name is up to 30 characters (may not be null-terminated)

Table 22 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Model” type (indicated in Table 6 above).

TABLE 22 Battery Model Report SMB Protocol Byte Description Note Command Byte 22h Byte Count N = 03h–20h Data Byte 1 (Sub-Command) XDh X = 0h for Battery in Slot 0 X = 1h for Battery in Slot 1 X = 2h for Battery in Slot 2 X = 3h for Battery in Slot 3 Data Byte 2 (Report Status) 00h Successful Data Byte 3–Data Byte N ASCII string Battery model is up to 30 characters (may not be null-terminated)

Table 23 specifies value for the Command and Sub-command fields, Byte Count and Report Status bytes, and data bytes of a “Battery Information” Data Report message (indicated in Tables 1 and 5 above) of the “Battery Type” type (indicated in Table 6 above).

TABLE 23 Battery Type Report SMB Protocol Byte Description Note Command Byte 22h Byte Count N = 03h–20h Data Byte 1 (Sub-Command) XEh X = 0h for Battery in Slot 0 X = 1h for Battery in Slot 1 X = 2h for Battery in Slot 2 X = 3h for Battery in Slot 3 Data Byte 2 (Report Status) 00h Successful Data Byte 3–Data Byte N ASCII string Battery type (commonly battery chemistry) is up to 30 characters (may not be null-terminated).

In some embodiments, EC/KBC 11 is configured to follow the following behavioral rules for communication with microprocessor 5 over the SMB:

-   -   After Power On Reset, EC/KBC 11 is ready to accept PMD request         messages over the SMB and respond to them as soon as possible         with the following time-out limits:         -   After an EC Capabilities Request is received, the responsive             EC Capabilities Report is sent over the SMB within 25 ms,         -   After a System Status Request is received, the responsive             System Status Report is sent over the SMB within 25 ms,         -   After any Battery Information Request is received, the             respective Data Report is sent over the SMB within 50 ms,             and         -   Action Requests are executed immediately upon receipt.     -   After Power On Reset, EC/KBC 11 does not initiate any report         messages (although it may send report messages in response to         requests from microprocessor 5) until a first System Status         Report is successfully sent in response to request therefore         from microprocessor 5.     -   After the first System Status Report has been sent, EC/KBC 11         will initiate subsequent System Status Reports by itself         whenever any status information changes (e.g., if a battery is         connected or removed, or system sleep state changes, etc.). In         some implementations, there is an exception to this rule: in the         case that GPIO state is changed by EC/KBC 11 in response to a         GPIO control action request from microprocessor 5, EC/KBC 11 may         not generate a System Status Report.     -   EC/KBC 11 is configured to handle the case that a new Data         Request is received from microprocessor 5 before EC/KBC 11 has         sent one or more previously requested Data Reports in response         to one or more previous Data Requests. In some implementations,         EC/KBC 11 responds with one Data Report to all duplicated Data         Requests (with the same command and sub-commands fields).

Notebook 100 of FIG. 3 is an embodiment of the inventive notebook which includes an auxiliary display subsystem (PMD 103) coupled by an SMB or I2C bus to an embedded controller (EC/KBC 11) of notebook 100. All elements of FIG. 3 that correspond to identical elements of above-described FIG. 1 are numbered identically in FIGS. 1 and 3, and the description thereof will not be repeated with reference to FIG. 3.

Notebook 100 differs from notebook 1 in that PMD 103 of notebook 100 does not include its own auxiliary display. PMD 103 generates display data of the same type that are displayed on auxiliary display 7 of notebook 1, but sends the display data to timing controller 108 (following optional processing) with proper timing for display on all or part of the screen of main display 107. Main display 107 of notebook 100 can be identical to main display 17 of notebook 1, but is coupled to receive display data from timing controller 108 rather than display data directly from graphics chipset 15. Alternatively, main display 107 is replaced by a main display that includes timing controller 108 and an array of pixels (backlit liquid crystal cells or other light-emitting elements), and timing controller 108 asserts display data to the pixels (or column drivers or other pixel driving circuitry) of the main display.

Timing controller 108 is configured to be operable in a mode in which it generates display data from raw display data asserted thereto by microprocessor 105 (e.g., by scaling the raw display data) and asserts the scaled data with timing for display on the screen of display 107 (e.g., in a small region of the screen of display 107), and also to be operable to assert display data from graphics chipset 15 for display on the screen of display 107. Optionally, timing controller 108 is configured to be operable in a mode in which it combines (multiplexes) display data from microprocessor 105 (or a scaled version of such data) with display data from graphics chipset 15 (e.g., so that data from microprocessor 105 or a scaled version thereof can be displayed in a small region of display 107's screen, while display data from graphics chipset 15 is displayed on the rest of display 107's screen).

Preferably, display 107 is an LCD of a type whose pixels (individual backlit liquid crystal cells) can be independently lit (e.g., independently backlit by independently controllable LEDs or other light sources) or a display of another type whose pixels can be independently powered and lit (e.g., independently backlit by independently controllable LEDs or other light sources). In such preferred embodiments, microprocessor 105 generates display data and asserts the display data (e.g., as 8-bit display data over a parallel link, or as serial data over an LVDS, or “low voltage differential signaling,” serial link) for display in only a small region of the screen of display 107, and timing controller 108 asserts the display data (or a scaled version thereof) to the screen of display 107 with appropriate timing for display in the appropriate small region of display 107's screen. Microprocessor 105 is preferably configured to power only the pixels of display 107's screen in the region in which the display data from PMD 103 are to be displayed, thereby conserving power (e.g., when notebook 100 is in a sleep or other low-power state).

In the case that microprocessor 105 of PMD 103 is coupled by an SMB to EC/KBC 11, microprocessor 105 can be identical to microprocessor 5 of FIG. 1. In this case, messages are preferably sent between microprocessor 105 and EC/KBC 11 in the format described above with reference to Tables 1-23. In the case that microprocessor 105 of PMD 103 is coupled by an I2C bus to EC/KBC 11, messages of the same type described above with reference to Tables 1-23 can be sent between microprocessor 105 and EC/KBC 11 in an appropriate format that will be apparent to those of ordinary skill in the art in view of the description herein.

In the implementation shown in FIG. 4, timing controller 108 includes scaling circuit (“scaler”) 58 and multiplexer 59, connected as shown. Scaler 58 is coupled and configured to generate display data by scaling raw display data asserted thereto (as serial data over an LVDS link, or over another link) from microprocessor 105, and to assert the display data over an LVDS link (or other link) to multiplexer 59. In some embodiments, scaler 58 is operable (under control of microprocessor 105) in at least two modes: a mode in which it downscales the raw display data both horizontally and vertically; and a mode in which it passes through the raw display data without scaling it. Multiplexer 59 has an input coupled to receive the display data output from scaler 58, a second input coupled to receive display data asserted by graphics chipset 15 over an LVDS link (or other link) between chipset 15 and multiplexer 59, and an output coupled to main display 107 by an LVDS link (or other link). Multiplexer 59 can be controlled to assert the data it receives from scaler 58 to main display 107 with timing for display in a region (e.g., determined by control bits or other signals from microprocessor 105) of display 107's screen. For example, when no display data are asserted from graphics chipset 15 to multiplexer 59 (e.g., when notebook elements including PC chipset 9 and graphics chipset 15 are in a standby state or other low-power state), multiplexer 59 can assert the data it receives from scaler 58 to main display 107, with timing for display in a small region of display 107's screen (e.g., with no display of data on the rest of display 107's screen). Multiplexer 59 can be controlled (e.g., while the notebook is in a fully powered state) to assert the data it receives from graphics chipset 15 (rather than the data it receives from scaler 58) to main display 107 with timing for display on display 107's screen.

In some embodiments, multiplexer 59 can be controlled to generate combined data by multiplexing the data received at its inputs, and to assert the combined data to main display 107 with timing such that when the combined data are displayed on main display 107, display data from microprocessor 105 (or a scaled version thereof) are displayed in a region (e.g., a small region) of display 107's screen, and display data from graphics chipset 15 are displayed on the rest of display 107's screen.

In alternative embodiments, scaler 58 is omitted and timing controller 108 includes a multiplexer (e.g. multiplexer 59) that can be controlled to assert raw auxiliary display data it receives from microprocessor 105 (or another element of an auxiliary display subsystem) to main display 107 for display on display 107's screen. Preferably, such multiplexer can also be controlled (e.g., while the notebook is in a fully powered state) to assert data it receives from graphics chipset 15 (rather than data it receives from the auxiliary display subsystem) to main display 107 with timing for display on display 107's screen.

Main display 107 can be implemented as shown in FIGS. 5 and 6 as an LCD panel 207 (to be referred to herein as main display 207). Main display 207 includes an array 201 of LCD cells and an array 202 of LEDs (light-emitting diodes) for illuminating the LCD cells of array 201. Each LED of array 202 underlies an LCD cell (or a small number of adjacent LCD cells) of array 201 and is capable of backlighting the LCD cell or cells that it underlies. Array 202 is mounted on printed circuit board (PCB) 203. PCB 203 implements a circuit for independently powering the individual LEDs of array 207 (or for independently powering rows and columns of the LEDs of array 207). This circuit is controlled by control signals asserted thereto from microprocessor 105. In typical operation in which microprocessor 105 controls scaler 58 and multiplexer 59 to cause the display of scaled data from microprocessor 105 in a region of display 107's screen (i.e., a small region determined by a backlit subset of the LCD cells of array 201), microprocessor 105 asserts control signals to PCB 203 to cause only those LEDs of array 207 that underlie the relevant subset of the LCD cells of array 201 to be powered.

Thus, microprocessor 105 can control the consumption of power by main display 207 to prevent consumption of power by those pixels that are not needed to display scaled data from microprocessor 105 in a region (e.g., a small region) of display 107's screen. With reference to FIG. 6, microprocessor 105 may assert display data to timing controller 108, and control the timing controller 108 to cause the display of scaled version of this data on a region of screen 210 (of display 207) determined by N rows of M columns of the pixels 211 of display 207 (where display 207 has many more than N rows of pixels 211 and many more than M columns of pixels 211). Each pixel 211 is determined by an LCD cell of array 201. Preferably, only those LEDs of array 207 that underlie the relevant subset of LCD cells of array 201 are powered (to backlight those LCD cells) while the scaled data are displayed in the N pixel×M pixel region on display 207's screen.

In other embodiments of the inventive notebook, a main display (e.g., main display 107 of FIG. 4) includes an array of LCD cells and an array of independently controllable light sources (other than LEDs) for backlighting either selected subsets of the LCD cells or all of the LCD cells of the LCD cell array, and an element of the notebook's auxiliary display subsystem (e.g., microprocessor 105 of FIG. 4) can control the consumption of power by the main display to prevent consumption of power by pixels of the main display that are not needed to display data generated by the auxiliary display subsystem (or a processed version of such data). For example, the auxiliary display subsystem that includes microprocessor 105 of FIG. 4 may prevent consumption of power by pixels of such an implementation of main display 107 that are not needed to display (in a small region of display 107's screen) a scaled version of data generated by the auxiliary display subsystem.

In other embodiments of the inventive notebook, a main display (e.g., main display 107 of FIG. 4) is of another type whose pixels can be independently powered and lit (e.g., independently backlit by independently controllable LEDs or other light sources), and an element of the notebook's auxiliary display subsystem (e.g., microprocessor 105 of FIG. 4) can control the consumption of power by main display 107 to prevent consumption of power by those pixels of the main display that are not needed to display data generated by the auxiliary display subsystem (or a processed version of such data).

In a class of implementations of the FIG. 4 circuitry, microprocessor 105 (or another element of the auxiliary display subsystem that includes microprocessor 105) generates display data and asserts the display data as serial data over an LVDS serial link for display (or processing followed by display) on the main display of a notebook. In other embodiments, an auxiliary display subsystem generates display data and asserts the display data (e.g., as 8-bit display data, or N-bit display data where N is not equal to 8, over a parallel link, or as serial data over a serial link other than an LVDS link) for display on the main display of a notebook (e.g., in only a small region of the screen of the main display).

In a class of embodiments of the inventive notebook, an auxiliary display subsystem (e.g., microprocessor 105 or another element of the auxiliary display subsystem that includes microprocessor 105) and a main display of the notebook are configured to power selected pixels of the main display in a region of the main display's screen in which data from the auxiliary display subsystem (or a scaled version of such data) are to be displayed, thereby conserving power (e.g., when the notebook is in a sleep or other low-power state).

We next describe embodiments of the invention with reference to FIG. 7, which is a block diagram of elements of a notebook computer (notebook 400) that embodies the invention. Notebook 400 includes conventional PC chipset 405 (including a CPU which runs the notebook's operating system software when the notebook has been booted into a fully-powered normal operating mode), memory 407 coupled to chipset 405, embedded controller 403 (which also functions as a keyboard controller), auxiliary processor 411, main display 413, graphics chipset 415, multiplexer 412 (having inputs coupled to auxiliary processor 411 and graphics chipset 415, and an output coupled to display 412), keyboard 402, touch pad device 425 including GPIO interface 427 coupled to auxiliary processor 411 by a serial bus and processor 426 coupled to controller 403 in a conventional manner, finger print sensor 409 (coupled to chipset 405 by a four-wire USB link and to auxiliary processor 411 by a serial link (preferably a two-wire link), content source 419 (e.g., a DVD drive, or another device that generates and/or stores display data, audio data, or other content), mass storage device 423 (which can be a hard disk drive, sometimes referred to herein as an “HDD”), multiplexer 417 (having an input coupled to content source 419, and outputs coupled to auxiliary processor 411 and PC chipset 405), and multiplexer 421 having an input coupled to mass storage device 423, and outputs coupled to auxiliary processor 411 and PC chipset 405).

Embedded controller 403 (which also functions as a keyboard controller) includes a GPIO interface that is coupled by a serial bus (e.g., an SMB, I2C bus, or other two-wire serial bus, or a USB link) to auxiliary processor 411. Embedded controller 403 is also coupled by a conventional link to keyboard 402, and is optionally also coupled by a four-wire USB link to chipset 405.

In some implementations, auxiliary processor 411 of FIG. 7 functions as a USB hub (e.g., for communication between each of fingerprint sensor 409, keyboard 402, and touch pad device 425 and PC chipset 405). In such implementations, fingerprint sensor 409, keyboard 402, and touch pad device 425 can be implemented inexpensively as dumb USB devices, rather than as more expensive, stand-alone USB hubs as in a conventional notebook. In some variations on notebook 400 of FIG. 7, touch pad device 425 is replaced by a simple touch pad device that lacks a conventional touch pad processor (e.g., conventional touch pad processor 426), such touch pad device is coupled directly only to auxiliary processor 411 (not to controller 403), and auxiliary processor 411 is configured to interact with the simple touch pad device including by performing functions that would conventionally be performed internally by the touch pad processor of a more complex, conventional touch pad device (e.g. device 425) of a type that includes a touch pad processor.

Embedded controller 403 is coupled to chipset 405 by a conventional low pin count (“LPC”) bus, to touch pad 425 and keyboard 402 as described, to auxiliary processor 411 by a serial bus which is preferably a two-conductor serial bus (e.g., an SMB, I2C bus, or other two-wire serial bus), and typically also to other elements (not shown in FIG. 7) of the notebook. Auxiliary processor 411 is coupled to each of GPIO interface 427 (of touch pad device 425), finger print sensor 409, and multiplexer 412 by a serial link. Preferably, auxiliary processor 411 is coupled to each of GPIO interface 427 (of touch pad device 425) and finger print sensor 409 by an SMB, I2C bus, or other two-wire serial bus, and to multiplexer 412 by an LVDS serial link. Auxiliary processor 411 is coupled to an output of multiplexer 417 in a conventional manner (e.g., the manner in which PC chipset 405 would conventionally be coupled directly to content source 419), and auxiliary processor 411 is coupled to an output of multiplexer 421 in a conventional manner (e.g., the manner in which a PC chipset 405 would conventionally be coupled directly to mass storage device 423).

In some implementations of notebook 400, auxiliary processor 411 is the auxiliary processor of an auxiliary display subsystem (e.g., an auxiliary display subsystem of notebook 400 similar or identical to PMD 103 of FIG. 3) including elements shown in FIG. 7 and typically also elements of notebook 400 not shown in FIG. 7. For example, the auxiliary display subsystem could include an auxiliary display (e.g., a display distinct from main display 413 and coupled to auxiliary processor 411). In some notebooks that embody the invention and include a main display and an auxiliary display subsystem that includes an auxiliary display, there is no multiplexer between the auxiliary processor (of the auxiliary display subsystem) and the main display (e.g., there is no multiplexer corresponding to multiplexer 412 of FIG. 7), a graphics chipset (e.g., a graphics chipset corresponding to chipset 415 of FIG. 7) is directly coupled to the main display to assert display data thereto, and the auxiliary processor is neither directly coupled nor coupled via a multiplexer to the main display.

In some implementations of notebook 400 (and in variations on notebook 400), auxiliary processor 411 (or a similar auxiliary processor) is the auxiliary processor of an auxiliary display subsystem that includes additional elements not shown in FIG. 7 (e.g., elements of the types described with reference to the auxiliary display subsystem of FIG. 2). In any of the embodiments and implementations mentioned in this paragraph, the auxiliary display subsystem (or the auxiliary processor thereof) and keyboard are operable (without communicating with the CPU included in PC chipset 405 or other PC chipset of the notebook) when the notebook is in a low-power state.

In implementations of notebook 400 in which auxiliary processor 411 is the auxiliary processor of an auxiliary display subsystem similar or identical to PMD 103 of FIG. 3, auxiliary processor 411 can perform the functions of, and have the same structure as, auxiliary processor 105 of FIG. 3, provided that auxiliary processor 411 has a communication interface configured to be coupled to all of elements 403, 405, 412, 417, 421, and 427 as described with reference to FIG. 7 (rather than just to a PC chipset, embedded controller, and timing controller corresponding to elements 405, 403, and 412 of FIG. 7 or elements 9, 11, and 108 of FIG. 3). In other implementations, auxiliary processor 411 is the auxiliary processor of an auxiliary display subsystem of another type (e.g., an auxiliary display subsystem of notebook 400 consisting only of auxiliary processor 411 and optionally also flash memory or other memory accessible by auxiliary processor 411, and operable with elements 402, 403, 409, 417, 419, 421, 423, 412, 413, and 425 of notebook 400 in a standby state or other low-power state of notebook 400 to perform functions including authentication of a user who presents a fingerprint to fingerprint sensor 409 (e.g., using biometric data cached in memory of the auxiliary display subsystem), display (on display 413) of video or other image data from source 419 (or video or other image data cached in memory of the auxiliary display subsystem) or system status data from embedded controller 403, and playback of audio data from source 419 or mass storage device 423 (or audio data cached in memory of the auxiliary display subsystem) on loudspeakers (not shown) of notebook 400. In some implementations, notebook 400 (or a variations thereon) is configured to be operable (e.g., while in a standby state or other low-power state) to display auxiliary display data (e.g., auxiliary display data passed by multiplexer 412 to main display 413) on a portion of the main display's screen, or (e.g., while in a fully powered state) to display data from a graphics chipset (e.g., data from chipset 415 passed by multiplexer 412 to main display 413) on the main display's screen. In some embodiments, the inventive notebook is configured to display auxiliary display data (e.g., auxiliary display data passed by multiplexer 412 to main display 413) on the entire screen of the main display and/or to display auxiliary display data (e.g., from auxiliary processor 411) and display data from a graphics chipset (e.g., chipset 415) on different parts of the main display's screen.

In notebook 400 of FIG. 7, multiplexer 417 can be controlled to route data (e.g., video data, image data, other display data) from content source 419 to either auxiliary processor 411 or PC chipset 405. Similarly, multiplexer 421 can be controlled to route data (e.g., display data) from mass storage device 423 to either auxiliary processor 411 or PC chipset 405. In variations on notebook 400 of FIG. 7, one or both of multiplexer 417 and multiplexer 421 is (or are) omitted.

In some embodiments of the inventive notebook, the notebook includes one or both of: a multiplexer having an input coupled to a content source (e.g., a DVD drive) and outputs coupled to an auxiliary processor and a PC chipset; and a multiplexer having an input coupled to a hard disk drive and outputs coupled to an auxiliary processor and PC chipset 405.

In FIG. 7, embedded controller 403 can include a GPIO interface that is or implements a GPIO extender configured to translate each command received from auxiliary processor 411 into an appropriate format for processing by the remaining circuitry of controller 403 (e.g., into the format of a corresponding command received by any of a conventional keyboard controller). The GPIO interface of embedded controller 403 should translate keyboard data into an appropriate format for assertion over the relevant serial bus to auxiliary processor 411.

In some implementations of notebook 400, main display 413 is implemented to have an array of pixels that are selectively and individually powerable or an array of pixels of which rows and columns are selectively and individually powerable. In these implementations, notebook 400's auxiliary display subsystem or an auxiliary processor thereof (e.g., auxiliary processor 411 of FIG. 7) is configured to control main display 413 (e.g., while notebook 400 is in a standby state or other low-power state) to cause only a subset of the pixels of the main display (e.g., only those needed to display auxiliary display data) to be powered, and to display auxiliary display data on the powered pixels of the main display. In some such implementations, notebook 400 is configured to be operable (e.g., while in a low-power state) to display auxiliary display data on only a subset of the pixels of main display 413 (e.g., auxiliary display data asserted from auxiliary processor 411 are scaled and asserted to main display 413 with timing for display on a small region of the screen of main display 413) and some or all of the other pixels of main display 413 are not powered, or (e.g., while in a fully powered state) to display data from a main graphics subsystem (e.g., from graphics chipset 415) on main display 413 (e.g., on all pixels of main display 413, while all such pixels are powered).

In some implementations, the auxiliary processor of the inventive notebook (e.g., processor 5 of FIG. 1, processor 105 of FIG. 3, or processor 411 of FIG. 7) is configured to execute the software known as Tiny CLR software (which is a reduced version of the Common Language Runtime or “CLR” software) or the operating system software known as Windows CE software. Preferably, such implementations of the auxiliary processor consume much less power when executing such software than does the notebook's CPU (e.g., the CPU of PC chipset 9 of FIG. 1 or FIG. 3, or the CPU of PC chipset 405 of FIG. 7) when executing the notebook's operating system.

In any embodiment of the inventive notebook, when a first element (e.g., an auxiliary processor or other secondary processor) of the notebook is coupled by an SMB to a second element of the notebook (e.g., a keyboard controller), messages are preferably sent between the first element and second element over the SMB in the format described above with reference to Tables 1-23. In any embodiment of the inventive notebook, when a first element (e.g., an auxiliary processor or other secondary processor) of the notebook is coupled by an I2C bus to a second element of the notebook (e.g., a keyboard controller), messages of the same type described above with reference to Tables 1-23 can be sent between the first element and second element over the I2C bus in an appropriate format that will be apparent to those of ordinary skill in the art in view of the description herein.

In some embodiments, the inventive notebook comprises subsystems that are detachable from each other. For example, it is contemplated that some embodiments of the notebook will include an auxiliary display subsystem (e.g., PMD 3 of FIG. 1 or PMD 103 of FIG. 3) that is detachable (e.g., implemented as a detachable media player) from the remaining portion of the notebook.

Other aspects of the invention are methods implemented by any embodiment of the inventive notebook. For example, one such method is performed by a notebook including an auxiliary processor and a keyboard controller, and includes the step of: sending data from one of the auxiliary processor and the keyboard controller over a serial bus (e.g., an SMB, I2C bus or other two-wire serial bus), to the other of the auxiliary processor and the keyboard controller when the notebook is in a low-power state. The notebook can also include at least one other processor (e.g., a secondary processor or CPU), and the method can also include the step of sending data from one of the other processor and the keyboard controller to the other of the other processor and the keyboard controller when the notebook is in a fully powered state.

Another example of such a method is performed by a notebook including an auxiliary processor, a PC chipset, and at least one content source (e.g., a DVD drive) and includes the steps of: controlling a multiplexer to assert a signal (indicative of at least one of data, at least one address bit, and at least one control bit) from one of the content source and the auxiliary processor to the other of the content source and the auxiliary processor while the notebook is in a low-power state; and controlling the multiplexer to assert another signal (indicative of at least one of data, at least one address bit, and at least one control bit) from one of the content source and the PC chipset to the other of the content source and the PC chipset. Another example of such a method is performed by a notebook including an auxiliary processor, a PC chipset, and at least one hard disk drive, and includes the steps of: controlling a multiplexer to assert a signal (indicative of at least one of data, at least one address bit, and at least one control bit) from one of the hard disk drive and the auxiliary processor to the other of the hard disk drive and the auxiliary processor while the notebook is in a low-power state; and controlling the multiplexer to assert another signal (indicative of at least one of data, at least one address bit, and at least one control bit) from one of the hard disk drive and the PC chipset to the other of the hard disk drive and the PC chipset.

It should be understood that while some embodiments of the present invention are illustrated and described herein, the invention is defined by the claims and is not to be limited to the specific embodiments described and shown. 

1. A notebook, including: at least one auxiliary processor; a content source; a PC chipset including a CPU; and a multiplexer coupled between the content source, the auxiliary processor, and the PC chipset, wherein the multiplexer is has a first state in which it passes data from the content source to the auxiliary processor and a second state in which it passes data from the content source to the PC chipset.
 2. The notebook of claim 1, also including: a mass storage device; and a second multiplexer coupled between the mass storage device, the auxiliary processor, and the PC chipset, wherein the second multiplexer has a first state in which it passes data from the mass storage device to the auxiliary processor and a second state in which it passes data from the mass storage device to the PC chipset.
 3. The notebook of claim 1, wherein the content source is a DVD drive.
 4. The notebook of claim 1, wherein the mass storage device is a hard disk drive.
 5. A notebook, including: at least one auxiliary processor; at least one mass storage device; a PC chipset including a CPU; and a multiplexer coupled between the mass storage device, the auxiliary processor, and the PC chipset, wherein the multiplexer has a first state in which it passes data from the mass storage device to the auxiliary processor and a second state in which it passes data from the mass storage device to the PC chipset.
 6. The notebook of claim 1, wherein the mass storage device is a hard disk drive.
 7. A notebook, including: a keyboard controller; an auxiliary display subsystem including an auxiliary processor, wherein the auxiliary processor is coupled to the keyboard controller by a serial bus; a content source; a PC chipset including a CPU; and a multiplexer coupled between the content source, the auxiliary processor, and the PC chipset, wherein the multiplexer has a first state in which it passes data from the content source to the auxiliary processor and a second state in which it passes data from the content source to the PC chipset.
 8. The notebook of claim 7, wherein the serial bus is a two-wire serial bus.
 9. The notebook of claim 8, wherein the serial bus is an SMB.
 10. The notebook of claim 8, wherein the serial bus is an I2C bus.
 11. The notebook of claim 7, wherein the notebook is operable in a low-power state, and the auxiliary processor and the keyboard controller are configured to A communicate with each other via the serial bus, without communicating with the CPU, when the notebook is in the low-power state.
 12. A notebook, including: a keyboard controller; an auxiliary display subsystem including an auxiliary processor, wherein the auxiliary processor is coupled to the keyboard controller by a serial bus; a mass storage device; a PC chipset including a CPU; and a multiplexer coupled between the mass storage device, the auxiliary processor, and the PC chipset, wherein the multiplexer has a first state in which it passes data from the mass storage device to the auxiliary processor and a second state in which it passes data from the mass storage device to the PC chipset.
 13. The notebook of claim 12, wherein the content source is a DVD drive.
 14. The notebook of claim 12, wherein the mass storage device is a hard disk drive.
 15. A method of operating a notebook including an auxiliary processor, a PC chipset including a CPU, and at least one content source, said method including the steps of: (a) controlling a multiplexer to assert a signal indicative of at least one of data, at least one address bit, and at least one control bit from one of the content source and the auxiliary processor to the other of the content source and the auxiliary processor while the notebook is in a low-power state; and (b) controlling the multiplexer to assert another signal indicative of at least one of data, at least one address bit, and at least one control bit from one of the content source and the PC chipset to the other of the content source and the PC chipset.
 16. The method of claim 15, wherein step (b) is performed while the notebook is in a fully powered state.
 17. A method of operating a notebook including an auxiliary processor, a PC chipset, and at least one mass storage device, said method including the steps of: (a) controlling a multiplexer to assert a signal indicative of at least one of data, at least one address bit, and at least one control bit from one of the mass storage device and the auxiliary processor to the other of the mass storage device and the auxiliary processor while the notebook is in a low-power state; and (b) controlling the multiplexer to assert another signal indicative of at least one of data, at least one address bit, and at least one control bit from one of the mass storage device and the PC chipset to the other of the mass storage device and the PC chipset.
 18. The method of claim 17, wherein step (b) is performed while the notebook is in a fully powered state.
 19. The method of claim 17, wherein the mass storage device is a hard disk drive and step (b) is performed while the notebook is in a fully powered state 